home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1995 November
/
EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso
/
earcd
/
misc
/
noahsarc.lha
/
Noahs.Arc
/
Part9
< prev
next >
Wrap
Text File
|
1995-10-05
|
11KB
|
320 lines
Okay, hard drives.
In a sense, there's not a lot that can be said about them. They're just
another device, like Ram or the floppies. You CD from dh0 so there's no
noisy disk access, which is certainly nice. Faster too, as you might
imagine. There's no doubt they're great..just not as "necessary" as many
hard drive owners would have you believe. Remember, we're just talking about
storage here, not memory. Memory is what you need for great big neat
probably-Amiga-only graphics stuff. Storage is just that, storage.
*
In another sense, of course, they're simply fabulous.
*
One of the greatest things about the hard drive is the freedom to
incorporate all those little twenty to thirty-thousand byte programs onto
the Bench, whereas before there wasn't qui-i-i-te enough room. And it's
also nice to have the option of having two, three, or even four commands of
the same type at your fingertips, like GShow, Sview, ShowILBM and ShowAll
renamed Show, Show2, 3 and 4, and Play, 2, 3 and 4 for Sound, BMP, Play,
and Play8sv4. VERY nice, even.
*
To get a hard drive up, unless it auto-boots, you need a few things:
- HardDisk.device and/or .driver in df0:devs
- HardDisk.info in your Expansion drawer, if the controller makes one
- the proper MountList in df0:devs
- Mount and BindDrivers in df0:c
- an edited startup-sequence
As far as the startup-sequence goes, the idea is to get the hard drive
recognized as quickly as possible so you can run the commands and programs
from it, instead of the floppy. Something like:
SetPatch >nil:
BindDrivers ;only use if you have stuff in
the Expansion dir
Mount dh0: ;reads MountList in devs
dh0:c/Assign c: dh0:c ;here comes the speed
Assign devs: dh0:devs
Assign libs: dh0:libs
<etc>
Toss in all the rest of the stuff and you're there. When things are
running smoothly you'll want to get Select going, with different hard drive
Bench options.
*
The two main problems we face when running things from the hard drive are
Ram recovery and our Assigns. There'll be other snags along the way, but
those are the main babies. There's also a difference between trying to run
something from the hard drive that already runs from the floppy, and trying
to run something, like a download, for the first time. If you're trying to
get some balky download fired up and you've already tried a few things, don't
hesitate to slap it onto a floppy and take it from, uh, scratch.
The Ram recovery is the same as before: Quitting as many of the sub-
routines as possible and Anything Else You Can Think Of. The problem we
face that the floppy owners don't is that in many instances we're trying
to run programs/games that were never designed to have LoadWB, etc, run
before them, using up precious memory. For that matter, even Mount and
BindDrivers might be enough to kill it. So the best you can do is go
through the whole list, right down to Path Reset and removing the disks,
and hope for the best. Not to discourage you, though..I've gotten almost
everything to run from the hard drive. Some, like Flight Simulator, are
kind of cute: Try copying the 154,083-byte AmigaFS file to the hard drive
and it copies exactly 86,016 bytes..just enough to run the demo! ;)
The Assign stuff is fairly straightforward. Make sure you assign the
actual disk name to the hard drive's directory name. If the name's two
words use the format
Assign "Silent Service:" dh0:Games/SService
or to whatever directory the game's in. For sub-directories it would be
Assign "Silent Service/Sound:" dh0:Games/SService/Sound
Hopefully the Assigns will go smoothly. You never can tell when some
crazy program will seek out "df0:GameData" or something, seeking df0 by name
and stopping everything. With any luck the game'll pop up a requester so
you can find out what it's looking for so you can reassign it in the
scriptfile. You can try file-zapping it, looking for a "df0" that you can
change to "dh0", but I personally haven't had much success that way, especi-
ally with the store-bought programs because they're written in some pretty
esoteric codes. And for, uh, just that reason.
*
Basic description of my hard drive layout (Interlace mode, of course):
The DU takes up the top half of the screen, two CLI windows are across the
bottom with the hard drive's window taking up the rest. In the hard drive's
window are ten drawers, labeled:
Audio Bench Games Graphics Icons
Misc Modem Notepad Paint Test
That seems to just about cover everybody. I've got all the docs in Misc,
pics, animations and hacks in Graphics (633 files @ 11.3 megs), all the
usual stuff in Bench, and 5 megs of Games. I've also (blush) got almost a
meg of icons hogging up space. Test is empty; it's for when I need a drawer
to test a program that won't run out of Ram, etc. Along with the icon-less
directories like libs and c, I also have a small smattering of misc dirs
like Temp, X, and MyFiles.
Hard Drive Misc:
- As far as IconX goes, things are about the same. I always start my
scriptfiles off with a "dh0:c/cd dh0:", just so there's absolutely no doubt
in anybody's mind where things are at. After that you run your usual stuff
like deleting Ram and quitting FaccII, if mem is needed, and running your
Assigns. CD to the directory the program's in and you're off.
- While you usually/always want to CD in a scriptfile to the dir the file's
in, keep in mind it's something NOT to do if it won't run. Scriptfiles
are slightly tricky to begin with, and, as mentioned, an IconX scriptfile
isn't really recognized as being a "scriptfile", it's more of a "Files-to-
be-run" list, with IconX doing the dirty deed.
- ALWAYS wait a few seconds before rebooting if you've just used Ed to
re-edit some huge textfile, as it's still writing a backup copy to the t
dir. Even though it's a hard drive, it still takes a few seconds. This is
real important, as you may wipe out the hard drive's validation, which
happened, I admit, to me. I could still read from the drive, so it wasn't an
authentic "crash", but I still had to copy all my files over to flops and
reformat. I called it a "soft crash", and it wasn't pretty.
- You've just possibly wandered across this cute little uncopyable 297-
byte file on your game disks, named, perhaps appropriately enough, " ".
Yes, eight silly little spaces...eight tiny blank uncopyable little spaces
standing between defeat and victory. Which will it be?? For the answer,
please send $25 to the address listed below...you will receive in the mail
a small, black market program that will..no-no, just kidding. Actually,
I don't know what the heck it is. Some kind of small, uncopyable file
would be my guess. Regardless, I've gotten all my games that had it on
the disk to run. You make a copy of the game, rename it to (name)Boot, and
put it in df1. You can try it in df0 but all of mine like df1. Start up
the program from dh0, it'll start loading and at some point will access df1,
scratch around for a second reading the uncopyable file, and then you're
back to the hard drive.
- Chessmaster doesn't have the 297 file, but still needs to be in df1,
renamed. It makes this simply incredible access sound and then it's back to
the hard drive. Only the main game program Chessmaster has to be on the
boot disk, but it can't be Copied onto the disk, it has to be Maraudered,
like the 297 file, all of which means that you'll have a different boot disk
for each game with an uncopyable/Marauder-onlyable file on it.
- If "onlyable" is in the next edition of Webster's, I want the royalties.
- If you copy all the files over to the hard drive from the original
master Silent Service disk, voila, Guru-City when you try to run it. Make
a nice standard copy of it with Marauder, copy those files over instead,
runs just smooth as silk. Hmmm.
- You can often filezap programs that list df0 by default in their Save or
Load windows and have them pop up dh0 instead. DPaintII and IconLab1.2 are
two I recall. Sometimes it might have a different "df0:" for each Save or
Load requester, or for different functions, like saving pics or brushes, so
always Continue Search (Amiga-C) just to make sure.
- Sometimes a program has been written to look for a certain accompanying
file to be on the surface of the disk, not in a directory. In that case
you'd Rename the file to dh0 in the scriptfile, load up the prog (without
Run), and then Rename the file back when the program's through. There might
be the occasional use where it's more practical to copy it over, then delete
it when done.
- Make sure to "Assign sys: dh0:" in the st-seq, if you haven't.
*
And when you get the hard drive up and running and really want to fly,
you can always load up RamBench and CD to it...
When you are in Ram's lofty perch, girded by an army of commands and
looking down upon your empire of devices..you are soaring, my friend.
It could only be called a beautiful, final step to an evolution.
*
Excuse me, did I say "final"?
I must be wrong.
Some two hundred thousand bytes of commands immediately accessible out of
Ram, millions of bytes of storage, megs of memory, colors galore, a modem
telecommunications link to the world...
Sounds to me like it's only the beginning.
* * *
Well, that's about it. Let's all take a deep breath..ah-h-h-h-h! Yep,
feels pretty good knowin' all that fancy computer stuff. Yep, feels pretty
good bein' able to shuffle them icons all over the place, feels pretty good
knowin' you got the best of that ol' "manual"..
Yep, bet ya even found a thing or two buried in that ol' manual that
just might be more than handy someday...
Yep, bet ya dug through them DOS books and snagged a couple o' gems that
even the ol' BenchMaster don't know...
Yep, bet that all feels pretty good...
Yes, indeedy...
REAL good...
And honest, I think that's fine.
Because that means it's test time.
*